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Registry and Extensions for 
P-Multicast Service Interface Tunnel Attribute Flags 


Abstract 


The BGP-based control procedures for Multicast Virtual Private 
Networks (MVPNs) make use of a BGP attribute known as the 
"P-Multicast Service Interface (PMSI) Tunnel" attribute. The 
attribute contains a one-octet "Flags" field. The purpose of this 
document is to establish an IANA registry for the assignment of the 
bits in this field. Since the "Flags" field contains only eight 
bits, this document also defines a new BGP Extended Community, 
"Additional PMSI Tunnel Attribute Flags", that can be used to carry 
additional flags for the "P-Multicast Service Interface (PMSI) 
Tunnel" attribute. This document updates RFC 6514. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7902. 
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1. Introduction 


A BGP attribute, "P-Multicast Service Interface (PMSI) Tunnel" 

attribute is defined in [RFC6514]. This attribute, referred to as 
the "PMSI Tunnel" attribute in this document, contains a one-octet 
"Flags" field. Only one flag is defined in that RFC, but there is 


now a need to define additional flags. However, that RFC did not 
create an IANA registry for the assignment of bits in the "Flags" 
field. This document creates a registry for that purpose. In 


addition, there may be a need to define more than eight flags. 
Therefore this document defines a new BGP Extended Community, 
"Additional PMSI Tunnel Attribute Flags", that can be used to carry 
additional flags for the "PMSI Tunnel" attribute. A registry is also 
created for this Extended Community, allowing IANA to assign flag 
bits from the Extended Community’s six-octet value field. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2. Extending the "PMSI Tunnel" Attribute "Flags" Field 


In [RFC6514], only a single octet in the "PMSI Tunnel" attribute is 
defined to carry bit flags. This allows eight flags, which is 
unlikely to be sufficient for all future applications. 


This document defines a new Transitive Opaque Extended Community 
({[RFC4360] [RFC7153]), "Additional PMSI Tunnel Attribute Flags". It 
also defines a new bit flag in the "PMSI Tunnel" attribute "Flags" 
field, called the "Extension" flag. 


The "Additional PMSI Tunnel Attribute Flags" Extended Community MUST 
NOT be carried by a given BGP UPDATE message unless the following 
conditions both hold: 


o the given BGP UPDATE message is also carrying a "PMSI Tunnel" 
attribute, and 


o the "Extension" flag of that "PMSI Tunnel" attribute’s "Flags" 
field is set. 


The six-octet value field of the "Additional PMSI Tunnel Attribute 
Flags" Extended Community is considered to be a string of 48 one-bit 
flags. As shown in Figure 1, the leftmost bit (the most significant 
bit of the most significant octet) is bit 0, and the rightmost bit 
(the least significant bit of the least significant octet) is bit 47. 


0 1 2 3 
OL 2) 34 96: F-8) 9 O12 3 4S 6: 78 OO. 2 3A. '6. Fe 8. 9 0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


3 4 
AEE E E T E ee O a E E E 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Value Field of the "Additional PMSI 
Tunnel Attribute Flags" Extended Community 


A BGP speaker MUST NOT attach more than one "Additional PMSI Tunnel 
Attribute Flags" Extended Community to a given BGP UPDATE. If a 
given BGP UPDATE already contains an "Additional PMSI Tunnel 
Attribute Flags" Extended Community, a BGP speaker MUST NOT attach 
any additional such Extended Communities. 
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If a BGP speaker receives a BGP UPDATE with more than one "Additional 
PMSI Tunnel Attribute Flags" Extended Communities attached, only the 
flag settings in first occurrence of the Extended Community are 
Significant. Flag settings in subsequent occurrences of the Extended 
Community MUST be ignored. When propagating the UPDATE, all 
instances of the Extended Community other than the first SHOULD be 
removed. 


Suppose a BGP speaker receives an UPDATE message that contains a 
"PMSI Tunnel" attribute, but does not contain an "Additional PMSI 
Tunnel Attribute Flags" Extended Community. If the "Extension" flag 
of the "PMSI Tunnel" attribute is set, the UPDATE is considered to be 
malformed, and the "treat-as-withdraw" procedure of [RFC7606] MUST be 
applied. 


If a BGP speaker receives an UPDATE message that contains one or more 
"Additional PMSI Tunnel Attribute Flags" Extended Communities, but 
either (a) that UPDATE message does not contain a "PMSI Tunnel" 
attribute, or (b) the "Extension" flag of the "PMSI Tunnel" attribute 
is not set, then the Extended Community(ies) SHOULD be removed and 
SHOULD NOT be redistributed. The BGP UPDATE message MUST be 
processed (and if necessary, redistributed) as if the Extended 
Community(ies) had not been present. 


A BGP speaker that supports the current document, but does not 
recognize a particular flag (either in the" PMSI Tunnel" attribute 
"Flags" field or in the "Additional PMSI Tunnel Attribute Flags" 
Extended Community) MUST simply ignore that flag. If the BGP speaker 
propagates either the "PMSI Tunnel" attribute, the "Additional PMSI 
Tunnel Attribute Flags" Extended Community, or both along with the 
UPDATE message, it SHOULD leave the setting of the flag unchanged. 


It is possible that a particular application will require all members 
of a particular set of BGP speakers to support a particular flag. 

How it is determined whether all such BGP speakers support that flag 
is outside the scope of this document. 


In some situations, a BGP speaker may need to modify or replace the 
"PMSI Tunnel" attribute before propagating an UPDATE. If the 
"Extension" flag of the "PMSI Tunnel" attribute was set before the 
attribute is modified or replaced, but that flag is no longer set 
after the attribute is modified or replaced, any "Additional PMSI 
Tunnel Attribute Flags" Extended Communities MUST be removed before 
the UPDATE is propagated. If the "PMSI Tunnel" attribute is removed 
entirely before an UPDATE is propagated, the "Additional PMSI Tunnel 
Attribute Flags" Extended Communities (if any) MUST also be removed. 
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IANA Considerations 


IANA has created a new registry called "P-Multicast Service Interface 
(PMSI) Tunnel Attribute Flags" in the "Border Gateway Protocol (BGP) 
Parameters" registry. 


Per Section 5 of [RFC6514], a "PMSI Tunnel" attribute contains a 
"Flags" octet. The "Flags" field is a single octet, with bits 
numbered, left-to-right, from 0 to 7. IANA has initialized the 
registry as follows: 


Bit Position Description Reference 
(left to right) 

unassigned 

Extension This document 
unassigned 

unassigned 

unassigned 

unassigned 

unassigned 

Leaf Information Required (L) RFC 6514 


YODOBWNEFR OO 


"PMSI Tunnel" Attribute Flags 

The registration procedure for this registry is Standards Action. 
IANA has also assigned the codepoint 0x07 from the "First Come, First 
Served" range of the "Transitive Opaque Extended Community Sub-Types" 
registry for "Additional PMSI Tunnel Attribute Flags". 
IANA has established a registry for the bit flags carried in the 
"Additional PMSI Tunnel Attribute Flags" Extended Community. The 
bits are numbered 0-47, with 0 being the most significant bit and 47 
being the least significant bit. The registration policy for this 
registry is "Standards Action". 
The initial registry should be as follows: 

Bit Flag Name Reference 


0-47 Unassigned 


Additional "PMSI Tunnel" Attribute Flags 
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4. Security Considerations 


This document establishes an IANA registry, and defines a new 
Transitive Opaque Extended Community ([RFC4360], [RFC7153]). 


Establishment of an IANA registry does not raise any security 
considerations. 


While this document defines a new Extended Community for carrying bit 
flags, it does not define any of the bit flags in that Extended 
Community. Therefore, no security considerations are raised. 


This document defines a new flag, the "Extension" flag, in the "PMSI 
Tunnel" attribute. If a particular UPDATE contains a "PMSI Tunnel" 
attribute with this flag set, but the UPDATE does not contain an 
"Additional PMSI Tunnel Attribute Flags" Extended Community, then the 
UPDATE is considered to be malformed, and the "treat-as-withdraw" 
procedure of [RFC7606] is invoked. Thus, one can cause an UPDATE to 
be treated as a withdrawal by incorrectly setting this bit. 
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